perf: Reduce compile time by trimming template expansion in IBA #4476
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I was profiling the builds and saw that modules with lots of template expansion dominate the compile time. For example,
imagebufalgo_pixelmath.cpp alone took 290s to compile on my 2020 MacbookPro (!), and imagebufalgo_addsub.cpp took 84 seconds.
This is all due to the combnatorics of expanding IBA templates via the DISPATCH macros in imagebufalgo_util.h separately for every type that the arguments can be. But I claim that most combinations are rarely if ever used. I mean, how often does anybody need IBA::add() to add an int8 image to an int16 image? So this PR rewrites those macros to simplify the cases as follows:
The common pixel data types are float, half, unint8, and uint16.
Specialized versions are fully expanded only when the result and input images are one of these types. Images not of one of those types are first automatically converted to float to make them reduce to a common case. That makes uncommon pixel data types like (signed) int16 not expand the template, but rather convert to and from float and use the float specializations.
For binary and ternary operations (those with 2 or 3 image inputs), if the pixel types of the inputs doesn't match, we make sure they both are converted to float. So, for example, we don't need a specialized version that adds a half image to a uint16 image -- just convert them to float and use the common case. But we do specalize if the two inputs are both the same common case, such as adding two uint16 images.
Assume that commonly, the result image will either be float, or will be the same pixel data type as the inputs. Other combinations trigger assignment to a temporary float IB, then copying with convertion to the uncommon use-supplied result buffer.
Additionally, we cut down on a little bit more templating by moving some "deep" methods from the type-templated ImageBuf::Iterator to its type-generic non-templated base class IteraterBase.
The net result of all this is an awful lot less template expansion. With this in place, my laptop compiles imagebufalgo_pixelmath.cpp in 97s (vs 290 before) and imagebufalgo_addsub.cpp in 26s (from 84). It takes a big bite out of all the iba files, and reduces project-wide compile time by over 10%, around 30s out of 300 for a fresh, uncached, optimized build with 16 threads.